[Previous] [Next] [Index] [Thread]

Re: Re[2]: Java "security holes'



Albert Lunde wrote:
| Prior experience (with stuff like anti-virus software) that the approach
| that works the best is one that needs no configuration and offers
| the user only choices directly related to things they understand.
|
| So I think a centralized security policy server would be a good idea.
| 
| But the problem of _finding_ such a server is non-trivial too, with
| IP spoofing and DNS corruption lurking as possible attacks: you'd
| want to autheticate your "security policy" server, and do something
| prudent if it went off-line (say thru a denial-of-service attack).

	Yes, you would want to authenticate this machine.  But, even
if its not well authenticated, having it is a win.  This is because
its a second attack that must work.  However, there is an easier
solution than having hosts look for this machine, and that is having
the firewall inject the information into the top of the HTTP stream.
This means that any time a machine goes through your http proxy, it
gets this information.

	Eventually, we might have secure DNS.  Until then, we should
piggyback on the firewall.

| I suppose a client could cache some cryptographic information to
| verify that the server it is talking to "now" is the same one it
| talked to "the last time", which reduces the window for some 
| spoofing attacks.
| 
| I'm no expert, but it seems like there's a lot to worry about.
| 
| With mobile computers plus mobile code, a domain-based secuity
| policy might be hard to hold together,too.

	Thats a very good point.  A lot probably depends on the means
of mobility.


Adam

-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume


References: